Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-223.txt

Text File | 1994-12-08 | 34.1 KB | 831 lines | [TEXT/R*ch]

C.S.M.P. Digest             Sat, 12 Dec 92       Volume 1 : Issue 223

Today's Topics:

    Flattened (Single Fork) QuickTime Movies
    Powerbook track ball buttons (click and hold)
    ETO#8, Dinker & SLM (Shared Library Manager) ?
    Super-Floating Windows
    Spurious invalidation



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  You can post articles to any newsgroup by
mailing your article to [e-mail].  So, to post an
article to comp.sys.mac.programmer, you mail it to
[e-mail].  Note the '-' instead of '.'
in the newsgroup name.

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (David Wroblewski)
Subject: Flattened (Single Fork) QuickTime Movies
Date: 5 Nov 92 01:31:15 GMT
Organization: U S WEST Advanced Technologies

Does anyone have experience using the QuickTime FlattenMovie function to
create single fork ("flattened") movie files?  I am experiencing a possible
bug, or at least obscure behavior.

The behavior is this:  I flatten ordinary movie file A using a little custom program
that simply calls FlattenMovie, (producing file B) then FTP B round trip
(in binary mode) to a Unix machine and back (producing file C). A, B, and C all
have different names on my disk.

Now I delete file B.

Now Simple Player (and other players) fail trying to play the movie from file C, popping
up the standard "Looking for movie file B" dialog that Quicktime shows when it can't
quickly resolve a reference to a data file. Of course, I think that QuickTime should be
finding the self-same file (C) I told Simple Player to open, but it won't accept that answer,
it wants file B.  If I rename C to B, Simple Player can play it perfectly.

My theory is that somewhere inside the flattened movie file is an alias or other reference
to the flattened movie file B, which wasn't changed via the FlattenMovie procedure.
Since FlattenMovie was included in QuickTime exactly to handle the case of moving
movies to other (non-mac) file systems, this seems like a bug to me, and since I want to
write a "movie server" that can hand off movies to anyone who asks, without dictating the
name of the file it gets stored in, this is causing me real grief.

Has anyone else seen this, have ideas about what might cause it, or thoughts on how
I might debug it?  Pointers to public domain code that flattens movies would also be
appreciated, on the off chance that I am not using FlattenMovie correctly.

Thanks in advance.

David Wroblewski
U S WEST Advanced Technologies
Boulder, CO 80303
[phone]
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (John Evans)
Date: 5 Nov 92 21:59:33 GMT
Organization: Apple Computer Inc., Cupertino, CA

This was a bug in QuickTime 1.0 that hurt me once.  When you flatten a movie
and you ask it to include everything in the data fork, QT is supposed to set
a bit in the movie telling it to reference this new file and not use the
references to the old data files.  This was called something like the
"Self-Reference" bit.  Unfortunately, this bit was not being set in QT 1.0.

I'm not sure if there's any good way around this.  I know that this bug has
been fixed in QT 1.5.

Good luck!
- --
+========================+===============================================+
| John S. Evans          | These opinions are mine. Apple's opinions are |
| Collaborative Systems  | Apple's.  Any similarity is coincidental.     |
| Apple Computer, Inc    | "Why does it happen?  Because it happens.     |
| [e-mail]        |  Roll the bones."                       -Rush |
+========================+===============================================+

---------------------------

From: [e-mail] (David Dantowitz)
Subject: Powerbook track ball buttons (click and hold)
Date: 3 Nov 92 12:48:26 GMT
Organization: UCLA, Computer Science Department


Has anyone written a trackball hack (similar to the Kensington hack)
that allows you to have one of the track ball buttons click and hold?

Alternatively, how does one differentiate between the two buttons?

Thanks.

- --
David Dantowitz
[e-mail]

Singing Barbershop when I'm not doing parallel simulation

+++++++++++++++++++++++++++

From: [e-mail] (Christopher Klaus Larson)
Date: 5 Nov 92 20:56:19 GMT
Organization: College of Engineering - University of California - Davis

In article <[e-mail]> [e-mail] (David Dantowitz) writes:
>
>Has anyone written a trackball hack (similar to the Kensington hack)
>that allows you to have one of the track ball buttons click and hold?
>
>Alternatively, how does one differentiate between the two buttons?
>

I don't know about the new PB's (160,180,210,230) but in the older
models the two buttons were physically wired together so there is *no*
way to tell them apart from inside the machine.

- --Chris
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Andrew D. Christian)
Date: 6 Nov 92 12:31:53
Organization: MIT Artificial Intelligence Laboratory


In article <[e-mail]> [e-mail] (Christopher Klaus Larson) writes:

   I don't know about the new PB's (160,180,210,230) but in the older
   models the two buttons were physically wired together so there is *no*
   way to tell them apart from inside the machine.

At a talk the other week, David Levy (who designed the trackball for
the Duos) mentioned that the buttons on the PB 210 & 230 are in fact
electrically separate, but the driver software currently doesn't
discriminate between them.

        Andrew Christian
        [e-mail]

- --


         - Andy

---------------------------

From: [e-mail] (Louis Demers)
Subject: ETO#8, Dinker & SLM (Shared Library Manager) ?
Date: 5 Nov 92 13:00:12 GMT
Organization: Defence Research Establishment Valcartier

Hi,

    Even after reading the documentation of both packages, I still
    have some difficulty in seeing the difference between Dinker
    and the shared Library Manager. Can anybody explain what
    differences there are ?

        Also, while I understand that these are unsupported,  What
    future do you see for those packages ?  I would be very interested
    in basing our next project on the SLM, but what will
    happen if Apple gets tired of it and doesn't support it
    anymore ? Will the application be easily converted to a normally
    linked application ?

        Thanks
- --
| Louis Demers              | DREV, Defence Research Establishment,Valcartier |
| [e-mail] | POBox 8800, Courcelette,Quebec, CANADA, G0A 1R0 |
|            (131.132.48.2) | Office: [phone]       fax [phone] |
+---------------------------+-------------------------------------------------+

+++++++++++++++++++++++++++

From: [e-mail] (Leonard Rosenthol)
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
Date: Thu, 5 Nov 1992 18:50:24 GMT

In article <[e-mail]> [e-mail] (Louis Demers) writes:
>    Even after reading the documentation of both packages, I still
>    have some difficulty in seeing the difference between Dinker
>    and the shared Library Manager. Can anybody explain what
>    differences there are ?
>
    Although not a technical difference, the most important difference
is that the SLM was done in house at Apple (while Dinker was an outside
project) and that Apple has (sort of) standardied on the SLM as the "shared
library" scheme of choice for the Mac.  You will see future System Software
based on the SLM.

>        Also, while I understand that these are unsupported,  What
>    future do you see for those packages ?  I would be very interested
>    in basing our next project on the SLM, but what will
>    happen if Apple gets tired of it and doesn't support it
>    anymore ? Will the application be easily converted to a normally
>    linked application ?
>
    As noted above, the SLM will not be going away anytime soon.


- --
- -----------------------------------------------------------------------------
Leonard Rosenthol            Internet:     [e-mail]
Director of Advanced Technology        AppleLink:    MACgician
Aladdin Systems, Inc.            GEnie:        MACgician


+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik )
Date: Sat, 7 Nov 1992 07:32:01 GMT
Organization: Apple

In article <[e-mail]>, [e-mail] (Leonard
Rosenthol) wrote:
>
> In article <[e-mail]> [e-mail] (Louis Demers) writes:
> >    Even after reading the documentation of both packages, I still
> >    have some difficulty in seeing the difference between Dinker
> >    and the shared Library Manager. Can anybody explain what
> >    differences there are ?

>     Although not a technical difference, the most important difference
> is that the SLM was done in house at Apple (while Dinker was an outside
> project) and that Apple has (sort of) standardied on the SLM as the "shared
> library" scheme of choice for the Mac.  You will see future System Software
> based on the SLM.

Yes, Dinker was done by Apple ATG/East Coast for a special project. It was
never the intention to state Dinker as an official dynamic linking
system for MacOS.

> >        Also, while I understand that these are unsupported,  What
> >    future do you see for those packages ?  I would be very interested
> >    in basing our next project on the SLM, but what will
> >    happen if Apple gets tired of it and doesn't support it
> >    anymore ? Will the application be easily converted to a normally
> >    linked application ?

>     As noted above, the SLM will not be going away anytime soon.

Versions are available on ETOs, the next ETO (#9) will have a totally
revised version how to create shared library functions. Anyone who
read my MADA Frameworks article, forget 50% of the techniques, they
are revised (sigh),  but it's actually now much easier to convert
code to SLM use. For instance, you don't need to write special
constructor/destructor .cp files.

Kent
- -------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: [e-mail])
DISCLAIMER: Private activities on the Net.

---------------------------

From: [e-mail] (David S. Blumenthal)
Subject: Super-Floating Windows
Date: 4 Nov 92 20:51:19 GMT
Organization: OSU Statistical Computing Laboratory

I am writing a "virtual keyboard" utility that will emulate a keyboard
on screen.  I would very much like to have the keyboard in a window that
remains fully visible and accessible at all times.  Sounds like a floating
window?

OK.  Here's the trick.  The window stays in the front, no matter what
application is running.  The window itself is not associated with the
current application, however.  The utility will receive clicks in its
window, but will not cause the current application to move out of the
foreground.

What is the best way to do this?  Should I be kludging with jWNEFilters
to intercept events?  Should this be an application proper that does
something weird to not be brought to the front?  Can I do this with a
background only application (that has a window)?

I once saw First Things First doing this, I think.  Does anyone know how
they do it?  That would be pretty close to what I hope to achieve.

Thanks a lot.  Sorry about the length of this.

- -----------------------------------------------------------------------
| Dave Blumenthal                  | The Ohio State University        |
| [e-mail]   | Statistical Computing Laboratory |
- ------ There is a fine difference between insight and insanity. -------

The above post is not intended to represent my employer in any way.

+++++++++++++++++++++++++++

From: [e-mail] (Leonard Rosenthol)
Date: 4 Nov 92 23:31:41 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

In article <[e-mail]> [e-mail] (David S. Blumenthal) writes:
>I am writing a "virtual keyboard" utility that will emulate a keyboard
>on screen.  I would very much like to have the keyboard in a window that
>remains fully visible and accessible at all times.
>
>OK.  Here's the trick.  The window stays in the front, no matter what
>application is running.  The window itself is not associated with the
>current application, however.
>
>What is the best way to do this?
>
    The best way to do it is NOT to do it.  Doing a "super floating
window" (as you call it) involves a LOT of tricking of the system (and the
applications as well) including about a half-dozen (or more) trap patches,
changs to the "Macintosh Drawing Environment", and then dealing with programs
like MSWord 4.0 which do really stupid things (like scrolling screenbits when
the user clicks in the documents scroll bar).


>I once saw First Things First doing this, I think.  Does anyone know how
>they do it?  That would be pretty close to what I hope to achieve.
>
    It does all of the "sick hacks" that I talk about above.

    Historical Note: The concept of a "super floater" was first done at
MacHack '88 (wow, long time!) when Darin Adler (formerly of Apple, now of
General Magic) an Sean Parent (now of Apple) wrote a hack called "Overtime"
which was a clock which floated over EVERYTHING.

- --
- -----------------------------------------------------------------------------
Leonard Rosenthol            Internet:     [e-mail]
Director of Advanced Technology        AppleLink:    MACgician
Aladdin Systems, Inc.            GEnie:        MACgician

+++++++++++++++++++++++++++

From: [e-mail] (Mimir Reynisson)
Date: 6 Nov 92 08:42:13 GMT

Punch a hole in the GrayRgn and do all your drawing in it. The window
manager will respect that hole at all times.

+++++++++++++++++++++++++++

From: [e-mail] (Grobbins)
Date: 7 Nov 92 08:46:26 GMT
Organization: Macintosh Hired Gun

In article <[e-mail]> [e-mail] (Mimir Reynisson) writes:
>Punch a hole in the GrayRgn and do all your drawing in it. The window
>manager will respect that hole at all times.

This method is problematic.  For one thing, removing a portion of a
monitor from the gray region will confuse the Finder, and it will start
repositioning any icons which happened to have been located under that
window.

Another issue is that, once your window is off the gray region, the
window manager wants nothing to do with you, so you end up doing most
window management chores manually.

The most serious problem is that punching a hole assumes that you can
unpunch the hole later (if the window moves or closes).  That requires
knowing what the gray region should be, but what it was when you
punched the hole may not be what it is when you attempt to unpunch the
hole.  (The gray rgn changes if, say, one of the monitors has moved.)
It is not safe to assume that the gray region should be restored to
whatever it was when the hole was punched.

Sorry, but at present I don't know of a good answer on how to proceed
on this.


Grobbins                 [e-mail]

Usual disclaimers apply.


+++++++++++++++++++++++++++

From: [e-mail] (Rich Siegel)
Date: 7 Nov 92 18:56:17 GMT
Organization: GCC Technologies

In article <[e-mail]> [e-mail] (Grobbins) writes:

>The most serious problem is that punching a hole assumes that you can
>unpunch the hole later (if the window moves or closes).  That requires
>knowing what the gray region should be, but what it was when you
>punched the hole may not be what it is when you attempt to unpunch the
>hole.  (The gray rgn changes if, say, one of the monitors has moved.)
>It is not safe to assume that the gray region should be restored to
>whatever it was when the hole was punched.

Actually, monitors can't move except across restarts of the system, so
unless some other program messes with the GrayRgn, you can probably
un-punch your hole. It isn't safe to simply restore the GrayRgn, but
you can probably UnionRgn the punched hole back in.

R.


- --
- -----------------------------------------------------------------------
Rich Siegel                              Internet: [e-mail]
Software Engineer & Toolsmith
GCC Technologies

+++++++++++++++++++++++++++

From: [e-mail] (Grobbins)
Date: 8 Nov 92 04:00:24 GMT
Organization: Mac Look & Feel, Apple Computer, Inc.

In article <[e-mail]> [e-mail] (Rich Siegel) writes:
>Actually, monitors can't move except across restarts of the system, so
>unless some other program messes with the GrayRgn, you can probably
>un-punch your hole. It isn't safe to simply restore the GrayRgn, but
>you can probably UnionRgn the punched hole back in.

Looking towards the future, this is not a good assumption.  Do not
assume that the GrayRgn is static or that monitors cannot move.


Grobbins                       [e-mail]

Usual disclaimers apply.



+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: Mon, 9 Nov 1992 21:00:38 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Rich Siegel)
wrote:
>
> In article <[e-mail]> [e-mail] (Grobbins) writes:
>
> >The most serious problem is that punching a hole assumes that you can
> >unpunch the hole later (if the window moves or closes).  That requires
> >knowing what the gray region should be, but what it was when you
> >punched the hole may not be what it is when you attempt to unpunch the
> >hole.  (The gray rgn changes if, say, one of the monitors has moved.)
> >It is not safe to assume that the gray region should be restored to
> >whatever it was when the hole was punched.
>
> Actually, monitors can't move except across restarts of the system, so

Well, I would say that monitors currently might not move, but don't make
any assumptions about the future.  Also, don't the Radius Pivot "move"
the monitor?

- -----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc."

+++++++++++++++++++++++++++

From: [e-mail] (Eric Schlegel)
Date: 09 Nov 92 16:54:23 GMT
Organization: Microsoft Corporation

In article <[e-mail]> [e-mail] (David S. Blumenthal) writes:
>I am writing a "virtual keyboard" utility that will emulate a keyboard
>on screen.  I would very much like to have the keyboard in a window that
>remains fully visible and accessible at all times.  Sounds like a floating
>window?
>
>OK.  Here's the trick.  The window stays in the front, no matter what
>application is running.  The window itself is not associated with the
>current application, however.  The utility will receive clicks in its
>window, but will not cause the current application to move out of the
>foreground.

This would be a perfect application of an input method, as supported by
the Text Services manager in System 7.1. The Text Services manager is
designed to do exactly what you want. The drawback, of course, is that
you have to require 7.1. Documentation is also rather scarce at this point -
I think only people who get the monthly developer mailing from Apple have
gotten the 7.1 seed disks so far. Hopefully the Developer CDs will have
information soon, though.

- -eric
- -------
My opinions, not Microsoft's.

+++++++++++++++++++++++++++

From: [e-mail] (Mimir Reynisson)
Date: 10 Nov 92 16:05:27 GMT

You can do a UnionRgn and then call PaintBehind() to force the window
manager to update its windows and redraw the desktop. Actually the
window Manager ignores the grayrgn. You can see it if you
punch a whole in your grayrgn and then go and select a menu.
It draws right over your window, silly menu manager :)

+++++++++++++++++++++++++++

From: [e-mail] (David S. Blumenthal)
Date: 10 Nov 1992 21:08:06 GMT
Organization: OSU Statistical Computing Laboratory

Thanks to all who have contributed to this thread so far.  It has helped me
out immensely.

I've done some testing with the "hole in GrayRgn" approach, and it works
sufficiently.  I think that as long as the part of GrayRgn that the window
removes does not stop corresponding to a piece of a monitor, there shouldn't
be any foreseeable problems.  If it does, however, any window in that area
will be affected.

As pointed out, menus function correctly over the affected region.  However,
the window manager does not ignore GrayRgn - update events are not generated
for my window.  Does anyone have any good ideas on how to determine when part
of my window must be redrawn?  Do InvalRect and InvalRgn check for intersection
with GrayRgn?  If not, could I check for intersection between my holeRgn and
the window port's updateRgn?  When would I do this?

The only other events I am interested in are mouseDown and mouseUp.  These get
to the window without regard to GrayRgn.  In order to catch all clicks over my
window, regardless of what would normally overlap, and of what application is
frontmost, I will patch SystemEvent and check theEvent.where (as suggested by
the UseNet Mac Programming Guide).

I really appreciate your comments.

- -----------------------------------------------------------------------
| Dave Blumenthal                  | The Ohio State University        |
| [e-mail]   | Statistical Computing Laboratory |
- ------ There is a fine difference between insight and insanity. -------

---------------------------

From: [e-mail] (Chris Spiral Catfish Tate)
Subject: Spurious invalidation
Organization: Computer Systems Laboratory, DCRT, NIH
Date: Fri, 6 Nov 1992 17:02:32 GMT

Situation: modal dialog, System 7.0.1, Mac IIfx

Problem: calling SetCTitle() (and possibly SetCtlValue()) on controls in the
dialog is forcing an update.  This is pretty bad in my case, since redrawing
the dialog is rather time-consuming.

Is this *really* what's happening?  According to the THINK C debugger, I'm
never calling InvalRect() or any of its relatives explicitly, but sure enough,
my userItem update routines are getting called the next time through
ModalDialog() after calling SetCTitle().

Does anyone have any idea what's happening, and how I might go about preventing
it?  Calling ValidRect() on the slow-to-draw userItem's rectangle after the
call to SetCTitle() doesn't seem to solve the problem; it's still updated.

As always, thanks in advance for whatever light you can shed on this...

- ------------------------------------------------------------------------------
Christopher Tate             | The Leadfoot Collection, Continued:
Management System Designers  |        * Red Barchetta (Rush)
                             |        * Old Time Rock And Roll (Bob Seeger)
[e-mail]    | Because driving fast is a cathartic experience.

+++++++++++++++++++++++++++

From: [e-mail] (Tim Dierks, software saboteur)
Date: Fri, 6 Nov 1992 22:42:36 GMT
Organization: MacDTS Marauders

In article <[e-mail]>, [e-mail]
(Chris Spiral Catfish Tate) wrote:
> Problem: calling SetCTitle() (and possibly SetCtlValue()) on controls in the
> dialog is forcing an update.  This is pretty bad in my case, since redrawing
> the dialog is rather time-consuming.
>
> Does anyone have any idea what's happening, and how I might go about preventing
> it?  Calling ValidRect() on the slow-to-draw userItem's rectangle after the
> call to SetCTitle() doesn't seem to solve the problem; it's still updated.

Sure enough, controls will invalidate themselves (or the control manager
does it; I can't remember).  This isn't the real problem; the problem is
that your user items are being drawn when they don't need to be.  I would
stick a little code at the beginning of your user item drawing procedure
that makes sure that your user item intersects the union of the visRgn and
the clipRgn; this way you can be sure that your user item actually
needs to be redrawn before undertaking the task.  (For extra points,
only redraw the bits that need to be redrawn.)

Tim Dierks
MacDTS, why not?

+++++++++++++++++++++++++++

From: [e-mail] (James T Sokoloff)
Date: 7 Nov 92 17:21:36 GMT
Organization: Massachusetts Institute of Technology

In article <[e-mail]> [e-mail] (Tim Dierks, software saboteur) writes:
>In article <[e-mail]>, [e-mail]
>(Chris Spiral Catfish Tate) wrote:
>> Problem: calling SetCTitle() (and possibly SetCtlValue()) on controls in the
>> dialog is forcing an update.  This is pretty bad in my case, since redrawing
>> the dialog is rather time-consuming.
>
>Sure enough, controls will invalidate themselves (or the control manager
>does it; I can't remember).  This isn't the real problem; the problem is
>that your user items are being drawn when they don't need to be.  I would
>stick a little code at the beginning of your user item drawing procedure
>that makes sure that your user item intersects the union of the visRgn and
>the clipRgn; this way you can be sure that your user item actually
>needs to be redrawn before undertaking the task.  (For extra points,
>only redraw the bits that need to be redrawn.)
>
>Tim Dierks
The region to check is the Intersection (SectRgn) (I-184) of the visRgn
& clipRgn.  The UnionRgn would (under most cases) not avoid any drawing.
SectRgn will correctly compute the region of interest.

Other than that, this *is* the correct way to speed up the drawing...
- ---Jim Sokoloff

+++++++++++++++++++++++++++

From: [e-mail] (Bathsheba Grossman)
Date: 7 Nov 92 22:15:21 GMT
Organization: University of North Carolina Extended Bulletin Board Service

>>(Chris Spiral Catfish Tate) wrote:
>>> Problem: calling SetCTitle() (and possibly SetCtlValue()) on controls in the
>>> dialog is forcing an update.  This is pretty bad in my case, since redrawing
>>> the dialog is rather time-consuming.

>>stick a little code at the beginning of your user item drawing procedure
>>that makes sure that your user item intersects the union of the visRgn and
>>the clipRgn; this way you can be sure that your user item actually
>>needs to be redrawn before undertaking the task.

>>Tim Dierks
>The region to check is the Intersection (SectRgn) (I-184) of the visRgn
>& clipRgn.  The UnionRgn would (under most cases) not avoid any drawing.

You don't have to do this SectRgn if you're using BeginUpdate/EndUpdate
because BeginUpdate does it for you and puts the result in the visRgn,
then EndUpdate puts it back to normal.
Also, using UpdtDialog (IV-60) or UpdtControl (IV-53) instead of
DrawDialog/DrawControls might just solve the whole problem.  (There, you
knew IV was good for something.)

- -Sheba


- --
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        Technology, or the Experimental Bulletin Board Service.
           internet:  laUNChpad.unc.edu or 152.2.22.80

+++++++++++++++++++++++++++

From: [e-mail] (Chris Spiral Catfish Tate)
Date: 10 Nov 92 15:54:49 GMT
Organization: Computer Systems Laboratory, DCRT, NIH

Thanks to everyone who responded, either on the net or via email.

In summary, what's happening is that indeed, SetCTitle() is *both* redrawing
the control with its new title *and* causing an update event in the dialog.
I'm not quite clear on why it has to generate the update event, but that's
beside the point.

The update event is causing all userItem procedures installed for the dialog
to be called, whether or not they actually intersect the updateRgn established
by the invalidation of the control's bounding rectangle.  Checking to see
whether each userItem actually *needs* to be redrawn prevents having to wade
through all that (slow, DrawString) drawing unnecessarily.

If you're absolutely sure you don't have to update anything else when the
control changes its title, you can also call ValidRect() on its rectangle
immediately following the call to SetCTitle(), and the update will be
"cancelled."

- ------------------------------------------------------------------------------
Christopher Tate             | The Leadfoot Collection, Continued:
Management System Designers  |        * Red Barchetta (Rush)
                             |        * Old Time Rock And Roll (Bob Seeger)
[e-mail]    | Because driving fast is a cathartic experience.

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 10 Nov 92 22:22:10 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail]
(Chris Spiral Catfish Tate) wrote:
>
> Thanks to everyone who responded, either on the net or via email.
>
> In summary, what's happening is that indeed, SetCTitle() is *both* redrawing
> the control with its new title *and* causing an update event in the dialog.
> I'm not quite clear on why it has to generate the update event, but that's
> beside the point.

I looked into this when working on "Macintosh Programming Secrets." What
happens when you call SetCTitle is the following:

    _HideControl
    change the title of the control
    _ShowControl

_HideControl calls _EraseControl and then invalidates the area under the
control's bounds. This is correct behaviour for _HideControl. When
_ShowControl is called, the control is redrawn, but the area is still
marked invalid in the window's update region. The second drawing of the
control is the dialog manager responding to the update.

> If you're absolutely sure you don't have to update anything else when the
> control changes its title, you can also call ValidRect() on its rectangle
> immediately following the call to SetCTitle(), and the update will be
> "cancelled."

Right. Here's the section for MPS that deals with this issue. Note that it
assumes that, if a dialog item is not a static or edit text item, that it
is a control. This is not a valid assumption in all cases (as in the
original poster's, who had user items in his dialog).

/*******************************************************************************

    SetDialogItemTitle

    Change the text associated with a particular dialog item. This is a little
    tricky since there are two ways to change the text. If you are dealing
    with an EditText or StatText (static text) item, you must call SetIText.
    If you are dealing with a dialog item that is backed up by a Control
    Manager control (like a simple button, radio button, or checkbox), you
    must call SetCTitle.

    We determine what kind of dialog item we are dealing with by calling
    GetDItem. Returned in the RkindS parameter is a number that identifies
    what sort of item we are handling. First, we strip off the upper bit,
    which identifies the item as being enabled or disabled. Once that bit is
    removed, we can examine the kind of the item and act accordingly.

    Notice the special handling we give to controls when we call SetCTitle.
    This is to take care of Rexcessive flashingS as Online Companion puts it.
    When you call SetCTitle, the control manager first calls HideControl to
    remove the control with its old text from the screen. It then changes the
    controlUs title in the ControlRecord, and reshows the control by calling
    ShowControl. At this point, the control is properly shown on the screen
    with its correct, new title.

    However, thereUs a little time bomb lurking in the works. When HideControl
    was called, the Control Manager called InvalRect on the area the control
    occupied. Even though ShowControl was later called on the same area and
    everything is drawn correctly, that rectangle is still marked as invalid
    and is incorporated into the update region for the dialog. The event loop
    at the heart of ModalDialog will then get an update event for that area
    and redraw the button _again_! This can cause the button to flicker and
    flash more than we would like. We already know that that area is
    adequately drawn, so we tell the Event Manager to hoof it by validating it
    with a call to ValidRect.

*******************************************************************************/
void    SetDialogItemTitle(DialogPtr dlg, short item, Str255 *newTitle)
{
    short    iKind;
    Handle    iHandle;
    Rect    iRect;

    GetDItem(dlg, item, &iKind, &iHandle, &iRect);
    iKind &= ~itemDisable;                // Strip off the enable/disable bit
    if ((iKind == statText) || (iKind == editText)) {
        SetIText(iHandle, *newTitle);
    } else {
        SetCTitle((ControlHandle) iHandle, *newTitle);
        SetPort(dlg);
        ValidRect(&iRect);
    }
}


- -----
Keith Rollin
Phantom Programmer
Taligent, Inc.

---------------------------

End of C.S.M.P. Digest
**********************